home *** CD-ROM | disk | FTP | other *** search
-
- Greetings,
- I work for a small OEM of embedded process controls. This zip file
- contains 'CTRLC.C', the quick-n-dirty Ctrl-Break & Ctrl-C intercept we use in
- our systems, based on AT class motherboard. The file also contains the BIOS
- int 15h intercept we use. Most of the info was gleaned from The Programmers PC
- Sourcebook, by Thom Hogan, (the old blue one, not the error-ridden 2nd ed),
- and verified in the AT tech ref, MS-DOS programmer's guide, etc.
-
- Originally, we tried to handle Ctrl-Break via signal() calls.
- The code looked something like this:
-
- Boolean breakFlag = False;
-
- void breakHandler()
- {
- signal( SIGINT, breakHandler );
- breakFlag = True;
- }
-
- int main()
- {
- ...
- signal( SIGINT, breakHandler );
- ...
- }
-
- Problems with this approach were:
-
- 1. The handler had to be re-installed at each invocation. We found that
- it was possible to generate Ctrl-Break or Ctrl-C fast enough to
- bypass the handler, and dump the user back to dos. In our systems,
- this is a safety hazard, not a mere nuisance. (The custom co-processor
- is not informed of the shutdown, interrupt vectors remain hooked, etc)
-
- 2. There was no way to differentiate between a Ctrl-Break and a Ctrl-C.
- We are presently treating these keys identically, but someday ...
-
- We whipped up a quick-n-dirty ASM file to hook the BIOS int 1Bh, and
- DOS int 23h. We (belatedly) realized the three finger salute was another
- potential safety hazard, and added the AT BIOS int 15h intercept. Then PrtSc,
- then the SysRequst key. Later on, we decided to attempt to translate all ASM
- files over to (Borland extended) 'C', and from there to "all files compiled with
- the -P (CPP always) command switch". The (slightly modified) result is file
- CTRLC.C.
-
- The basics, in psuedo-ASM. Initialize by hooking interrupt vectors
- 0x1B and 0x23 to routines similar to these:
-
- public breakflag, new1Bh, new23h
-
- .data
- breakflag dw 0
-
- .code
-
- dGrp dw @data
-
- proc setFlag near
- push ds
- mov ds, [dGrp] ; load flag segment
- mov [breakflag], 1 ; set flag to boolean True
- pop ds
- ret
- endp setFlag
-
- proc new1Bh far
- call setFlag ; go set flag
- iret ; simple return to BIOS
- endp new1Bh
-
- proc new23h far
- call setFlag ; go set flag
-
- ; sti ; this would work, usually, but sometimes
- ; clc ; failed under QEMM, EMM386, etc.
- ; ret 2 ; something to do with the interrupt flag
- ; in virtual 86 mode, we think
-
- push bp ; this is more convoluted, but worked under
- mov bp, sp ; QEMM, etc, without disturbing the int flag
- push ax
- mov ax, [bp+6] ; fetch flags from stack
- and not 1 ; clearing carry tells DOS to continue
- mov [bp+6], ax ; put adjusted flags back
- pop ax ; restore & exit
- pop bp
- iret
- endp new23h
-
- The 'C' version of this formerly ASM file contains:
-
- void init_kybd(); // install interrupt intercepts
- void term_kybd(); // restore original interrupt vectors
- Boolean breakflag; // set True when Ctrl-Break or Ctrl-C hit
-
- Potential problems with our approach:
-
- 1. Supposedly, the infamous "Abort, Retry, Ignore, Fail" will abort
- via int 23h. For us, that's not a problem, because we also intercept
- int 24h (Critical Error), so we never abort, and never see this
- message anyway. (See Borland's harderr(), hardretn(), etc)
-
- 2. In some cases that we haven't really chased down yet, MS-DOS v5.00
- can and does remove a leading Ctrl-C from the keyboard buffer. This
- has something to do with disk access, which is about the only dos calls
- we make (Borland's memory calls during malloc(), etc are the others).
- This is one reason we Ctrl-Break and Ctrl-C are still treated the same.
-
-
- Note that our systems are multitaskers (preemptive and cooperative, and a BEAR
- to debug sometimes !). The multitasker, window system, data input, serial
- drivers, etc were all developed in-house (except Borland's run-time, and
- Raima's dbVista). We access the hardware via BIOS when we can (keyboard, lpt's), directly when we need to
- (video, aux's), and via DOS as a last resort (disk). All keyboard input calls
- use the AT extensions to BIOS int 16h. Keyboard input is a relatively low
- priority task.
-
- !! WHAT WORKS FOR US MAY NOT MEET YOUR NEEDS !!
-
- Obligatory legal stuff. These files are released into the public domain.
- You may use them, modify them, etc to your heart's content. The author (me)
- is NOT liable for any damages, lost profits, or any other problems caused by
- your use of these routines. They work for us, so far, but you USE AT YOUR OWN
- RISK !
-
- (Whew. Ought to put that on a hot-key.)
-
- Hope this is of some help. Questions are welcome, but may scroll off before
- I can catch them (another road trip tomorrow). If you don't get an answer,
- try again.
-
- Roger Pittman [Jolly Roger :-)]
- CI$ 74130,3011
-